Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/music/midispec.lzh/MIDISPEC.DOC

Text File | 1988-01-25 | 29KB | 637 lines

The official MIDI 1.0 specification is available from:
IMA
the International MIDI Association
11857 Hartsook St.
North Holllywoood, CA  91607
[phone]

The complete MIDI spec as developed by the Japanese manufacturers
and adopted by the "World" at the Summer '85 NAMM show
is available to IMA members ($40/yr) foor $30 non-members $35.

The sketchy hardware and byte definitions are free with membership.

The following is an expanded MIDI definition (sort of in-between
IMA MIDI 1.0 and the new $35 booklet) entered into the public
domain on USENET net.musi.synth by an altruistic musically
inclined engineer:

Bob McQueer
22 Bcy, 3151

All rites reversed.  Reprint what you like.


                       The USENET MIDI Primer
                            Bob McQueer

PURPOSE

It seems as though many people in the USENET community have an interest
in the Musical Instrument Digital Interface (MIDI), but for one reason
or another have only obtained word of mouth or fragmentary descriptions
of the specification.  Basic questions such as "what's the baud rate?",
"is it EIA?" and the like seem to keep surfacing in about half a dozen
newsgroups.  This article is an attempt to provide the basic data to
the readers of the net.

REFERENCE

The major written reference for this article is version 1.0 of the MIDI
specification, published by the International MIDI Association, copyright
1983.  There exists an expanded document.  This document, which I have not
seen, is simply an expansion of the 1.0 spec. to contain more explanatory
material, and fill in some areas of hazy explanation.  There are no
radical departures from 1.0 in it.  I have also heard of a "2.0" spec.,
but the IMA claims no such animal exists.  In any event, backwards
compatibility with the information I am presenting here should be
maintained.

CONVENTIONS

I will give constants in C syntax, ie. 0x for hexadecimal.  If I
refer to bits by number, I number them starting with 0 for the low
order (1's place) bit.  The following notation:

>>

text

<<

will be used to delimit commentary which is not part of the "bare-
bones" specification.  A sentence or paragraph marked with a question
mark in column 1 is a point I would kind of like to hear something
about myself.

OK, let's give it a shot.

PHYSICAL CONNECTOR SPECIFICATION

The standard connectors used for MIDI are 5 pin DIN.  Separate sockets
are used for input and output, clearly marked on a given device.  The
spec. gives 50 feet as the maximum cable length.  Cables are to be
shielded twisted pair, with the shield connecting pin 2 at both ends.
The pair is pins 4 and 5, pins 1 and 3 being unconnected:

                              2
                          5       4
                        3           1


A device may also be equipped with a "MIDI-THRU" socket which is used
to pass the input of one device directly to output.

>>
        I think this arrangement shows some of the original conception
        of MIDI more as a way of allowing keyboardists to control
        multiple boxes than an instrument to computer interface.  The
        "daisy-chain" arrangement probably has advantages for a performing
        musician who wants to play "stacked" synthesizers for a desired
        sound, and has to be able to set things up on the road.
<<

ELECTRICAL SPECIFICATION

Asynchronous serial interface.  The baud rate is 31.25 Kbaud (+/- 1%).
There are 8 data bits, with 1 start bit and 1 stop bit, for 320 microseconds
per serial byte.

MIDI is current loop, 5 mA.  Logic 0 is current ON.  The specification
states that input is to be opto-isolated, and points out that Sharp
PC-900 and HP 6N138 optoisolators are satisfactory devices.  Rise and
fall time for the optoisolator should be less than 2 microseconds.

The specification shows a little circuit diagram for the connections
to a UART.  I am not going to reproduce it here.  There's not much
to it - I think the important thing it shows is +5 volt connection
to pi 4 of the MIDI out with pin 5 going to the UART, through 220
ohm load resisors. It also shows that you're supposed to connect
to the "in" side of the UART through an optoisolator, and to the
MIDI-THRU on the UART side of the isolator.


>>
        I'm not much of a hardware person, and don't really know what
        I'm talking about in paragraphs like the three above.  I DO
        recognize that this is a "non-standard" specification, which
        won't work over serial ports intended for anything else.  People
        who do know about such things seem to either have giggling
        or gagging fits when they see it, depending on their dispos-
        itions, saying things like "I haven't seen current loop since
        the days of the old teletypes".  I also know the fast 31.25
        Kbaud pushes the edge for clocking commonly available UART's.
<<

DATA FORMAT

For standard MIDI messages, there is a clear concept that one device
is a "transmitter" or "master", and the other a "receiver" or "slave".
Messages take the form of opcode bytes, followed by data bytes.
Opcode bytes are commonly called "status" bytes, so we shall use
this term.

>>
        very similar to handling a terminal via escape sequences.  There
        aren't ACK's or other handshaking mechanisms in the protocol.

<<

Status bytes are marked by bit 7 being 1.  All data bytes must
contain a 0 in bit 7, and thus lie in the range 0 - 127.

MIDI has a logical channel concept.  There are 16 logical channels,
encoded into bits 0 - 3 of the status bytes of messages for
which a channel number is significant.  Since bit 7 is taken over
for marking the status byte, this leaves 3 opcode bits for message
types with a logical channel.  7 of the possible 8 opcodes are
used in this fashion,  reserving the status bytes containing all
1's in the high nibble for "system" messages which don't have a
channel number.  The low order nibble in these remaining messages
is  eelly ffuther  pcodee

>>
        II you are  nterested in rrceiving MIDI input, look over the
        SYSTEM messages even if you wish to ignore them.  Especially the
        "system exclusive" and "real time" messages.  The real time
        messages may be legally inserted in the middle of other data,
        and you should be aware of them, even though many devices won't
        use them.
<<

VOICE MESSAGES

I will cover the message with channel numbers first.  The opcode determines
the number of data bytes for a single message (see "running status byte",
below).  The specification divides these into "voice" and "mode" messages.
The "mode" messages are for control of the logical channels, and the control
opcodes are piggybacked onto the data bytes for the "parameter" message.  I
will go into this after describing the "voice messages".  These messages are:

status byte   meaning        data bytes

0x80-0x8f     note off       2 - 1 byte pitch, followed by 1 byte velocity
0x90-0x9f     note on        2 - 1 byte pitch, followed by 1 byte velocity
0xa0-0xaf     key pressure   2 - 1 byte pitch, 1 byte pressure (after-touch)
0xb0-0xbf     parameter      2 - 1 byte parameter number, 1 byte setting
0xc0-0xcf     program        1 byte program selected
0xd0-0xdf     chan. pressure 1 byte channel pressure (after-touch)
0xe0-0xef     pitch wheel    2 bytes giving a 14 bit value, least
                                   significant 7 bits first

Many explanations are necessary here:

For all of these messages, a convention called the "running status
byte" may be used.  If the transmitter wishes to send another message
of the same type on the same channel, thus the same status byte, the
status byte need not be resent.

Also, a "note on" message with a velocity of zero is to be synonymous
with a "note off".  Combined with the previous feature, this is intended
to allow long strings of notes to be sent without repeating status bytes.


>>
        From what I've seen, the "zero velocity note on" feature is very
        h